Clever solution! My only thought is how this might play with rotating the text. Will give this branch a go locally when I get a chance and report back

In the screenshot I set angle: -45.

I checked myself and it did not work with rotation. My new commit fixes it. Let me know if there are any problems.

Does this work on all (our supported) browsers? I remember reading that css transforms did not work on IE. It would be nice to support IE 11 if possible, although I know it's on it's way out (github is dropping it in a few months).

From caniuse about IE11.

Does not support CSS transforms on SVG elements (transform attribute can be used instead)

All versions of Edge have the same problem unfortunately.

I can change it to use the transform attribute which means that em and rem don't work that nice anymore and would need to be calculated.

The problem of transforming em -> px is only there if no font-size is set on <Text /> (or stuff needs to go into the DOM which is not so nice).

Would it be a good tradeoff to set a default fontSize prop of maybe 11px that there is always a value to calculate dx and dy with?

That would get rid of the transforms, uses the correct svg attributes and works in supported browsers.

@sto3psl Since adding dx/dy on <text> conflicts with the <tspan>, maybe we could wrap the entire thing in a <g> and apply dx/dy to x/y?

Another thought is could you use reduce-css-calc like we are for verticalAnchor and convert it that way

change:

const x = textProps.x + dx;
const y = textProps.y + dy;

to

const x = reduceCSSCalc(`calc(${textProps.x}) + ${dx}`);
const y = reduceCSSCalc(`calc(${textProps.y}) + ${dy}`);

Wrapping <text /> in a <g /> could work.

The problem with reduceCSSCalc is if dx or dy are em values and textProps.x or textProps.y are px values.

reduceCSSCalc(`calc(5px + 1em)`) -> 'calc(5px + 1em)'

And 'calc(5px + 1em)' is not valid as x or y value. reduceCSSCalc can't handle mixed units.

@sto3psl oh, I thought it handled mixed units, but I see it does not. Hopefully the <g> route works. Thanks for digging into the problem.

Ok I played with svg a little and <g> does not work since it ignores x and y. We could wrap the <text> with a <svg> though and then we get px,em,rem support. According to the spec it's no problem if svg elements have svgs as child. See this codepen -> https://codepen.io/anon/pen/rvNGjz

Our Group uses <g transform={`translate(${x}), ${y})`} />. Maybe try using the svg transform method on g? You could also use the <Group> component to simplify it? I'm assuming svg transforms understand em/rem (like css transform).

If this doesn't work, the svg might be a decent approach (would be odd to have a lot of nested SVG components, not sure if this could have any corner case problems).

Svg transforms are unitless which means transforming em -> px again. The <svg> approach is really nice and Victory does a lot <svg> nesting too.

@sto3psl sounds like <svg> is the way to go then 😄. Thanks again

The <svg> seems to work nicely.

• The style={{ overflow: "visible" }} is necessary since the svg has no width and height and the text would otherwise not be visible.
• The fontSize has to be set so that the browser calculates em values correctly.

Thanks for all the input and thoughts on this @techniq. If there is anything else let me know, this was quite fun to think about 😄.

@sto3psl Thanks for digging in and finding a solution. I haven't had a chance to pull it down locally (@hshoff if you could take a quick peak that would be awesome) but I have no reason to expect any issues 😄

LGTM thanks for the contribution @sto3psl!